-
Notifications
You must be signed in to change notification settings - Fork 816
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix OTP type #1283
base: dev
Are you sure you want to change the base?
Fix OTP type #1283
Conversation
I feel like there are other places where this change needs to be made. E.g.
We really need to spend some time writing E2E tests. This change is scary to me because this enum is used in a lot of places where type checking is half broken due to vuex. |
675a1d9
to
cfd775f
Compare
@mymindstorm we should have a hotfix ASAP. |
found a bug:
the hotp code becomes a totp code |
this also occurs if you add a hotp when encryption is on and reload the extension |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has a bug in it.
this.type = OTPType.hex; | ||
} else if ((decryptedData.type as unknown) === 6) { | ||
this.type = OTPType.hhex; | ||
} else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line is causing the bug. This if statement is not considering if decryptedData.type
is a valid OTPType
already and will always return OTPType.totp
when decryptedData.type
is a string.
Recommend making a type guard for OTPType
and using it whenever we need to check if a type
is valid, such as in storage.ts
and elsewhere. Plus another shared function to convert from legacy otptype to new version. That would help prevent subtle mistakes like this and help remove all this casting to unknown.
@@ -617,29 +614,53 @@ export class EntryStorage { | |||
} | |||
|
|||
if (!entryData.type) { | |||
entryData.type = OTPType[OTPType.totp]; | |||
entryData.type = OTPType.totp; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
move this into the case statement or otherwise refactor so we don't have to cast to unknown below. we can set type: unknown
in otp.d.ts
/RawOTPStorage
type = OTPType.hhex; | ||
} else { | ||
type = OTPType.totp; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recommend keeping numeric enums where you get the benefit of reverse mappings so you don't have to do this ugly thing.
this.type = OTPType.hhex; | ||
} else { | ||
this.type = OTPType.totp; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(2) I recommend keeping numeric enums where you get the benefit of reverse mappings so you don't have to do this ugly thing.
// hex = 5 | ||
// hhex = 6 | ||
|
||
if ((entry.type as unknown) === 1) { |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Error OTP type entries would only ever be 1
, there is no need to check the other numbers.
// hex = 5 | ||
// hhex = 6 | ||
|
||
if ((decryptedData.type as unknown) === 1) { |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(2) Error OTP type entries would only ever be 1
, there is no need to check the other numbers.
Flow in question:
So in the currently deployed extension we have this line: Authenticator/src/models/storage.ts Line 481 in 6511920
From this point onwards, all equality checks on Authenticator/src/models/otp.ts Lines 156 to 160 in 6511920
Input Authenticator/src/models/storage.ts Lines 221 to 227 in 6511920
Type of Authenticator/src/models/storage.ts Lines 624 to 638 in 6511920
Now when loading an entry back in, the number Pretty significant bug I think, this PR is a high priority one for sure. |
The cause of this type bug: Authenticator/src/models/storage.ts Line 481 in 6511920
Do you think this is a TypeScript bug? @mymindstorm @Sneezry ? |
Fix #1271
We have both OTPType and string definitions for OTP entry types. Previously, OTPType was a numeric enum. When importing OTP URLs, OTP entries were generated with a numeric type value, causing an issue where the period parameter was ignored. This happened because we were comparing OTPType.totp (which has a numeric value of 1) with the string "totp", leading to a false condition. As a result, the system incorrectly identified the entry as not time-based, causing the period parameter to be disregarded. This fix ensures all OTP types are now aligned with the new OTPType string enum, resolving the issue.